This is how Boldare Development Teams process addresses your business needs
Boldare’s approach to digital product design and development is always focused on the client’s business needs. Over the last 20 years, we have established and perfected a process designed to fully meet our partners’ requirements. It’s deeply immersed in the agile software development philosophy and concentrates on delivering a working increment at a fast pace.
Table of contents
Our software development process is based on the Agile Manifesto and Scrum framework. But those are just tools which we use to ensure that our partners’ business needs will be fulfilled. Based on our experience, we believe that an agile approach is the most efficient way to deliver real business value to our partners. And our whole development process is designed to make it happen. So, how exactly do we do software at Boldare?
Our process
Product development kick-off
Before we start development, we go through a stage of collaboration and product kick-off. This is a series of events involving the client/partner and the whole team, led and facilitated by our Scrum Master. These include:
- Meet the team
- Discover the product
- Plan a release
During this phase, we all meet, discuss, and exchange information, but we are also looking for ideas, solutions, and, as a result, we create a Product Backlog and plan for the first release. To accomplish this, we use various techniques, which include:
- Event storming,
- Impact mapping,
- User story mapping,
- Planning poker,
- Design thinking.
We follow our checklists to make sure we cover all relevant topics.
Delivering product increment in 2 weeks
We follow the Scrum Guide (as defined by scrum.org) to organize our development. We work in 2-week sprints, delivering product increments and collaborating creatively with each other.
Every sprint includes:
- Sprint Planning (Development Team, Product Owner, Scrum Master)
- Daily Meeting (Development Team, Scrum Master)
- Sprint Review (Development Team, Product Owner, Scrum Master)
- Sprint Retrospective (Development Team, Product Owner, Scrum Master)
- Project management
Project management in Boldare relies on a Scrum Team, including the Product Owner, Scrum Master, and Development Team. These three roles, along with well-defined processes and responsibilities, cover our project management.
>>> A step by step guide to Event Storming – our experience
Budget, scope and change management
We deliver software using Scrum principles, which means changes are natural and can be introduced to the Product Backlog at any time, and then reflected in the Sprint Backlogs.
What do development scope and budget management look like in our process?
- The Development Team and Scrum Master are accountable for recommendations or decisions on how to approach the product development process, collaboration and feature/story solutions to find the best fit between development efficiency, product quality, and the client’s (Product Owner’s) budget expectations/limits.
- The Development Team is responsible for continuous estimation of Product Backlog items and tracking the work to ensure the most accurate information about the actual speed of delivery.
- The Product Owner is responsible for (non-technical) backlog decisions: scope (epics and stories), priorities (Product Backlog ordering), and formulating the most important scope to deliver in the current sprint and release.
- The Scrum Master and the Development Team are responsible for maintaining predicted delivery dates for releases (for example: when an MVP can be released), as defined by the Product Owner and estimated by the Development Team.
- By continually knowing the predicted delivery dates, scope, and Development Team size & structure, we can estimate budget for the release.
The above process is repeatedly iterated, with all parties involved, and is actually the budget and scope management of our software development process, giving the Product Owner (and other product stakeholders) more precise control and predictability than in any waterfall process, or in a top-down controlled environment.
Risk management
First identification of product development risk is performed before the product development starts, at the product discovery workshops. We organize a meeting with product stakeholders to identify and plan a response to risks.
During product development, risk management sessions are performed every iteration and are included in Scrum meetings. By generating frequent feedback from the team (including the QA roles), the Product Owner can react quickly and reduce problems before they really appear.
Every time a risk is identified we communicate it to product Stakeholders, including possible consequences, proposed solutions or actions to address the risk item.
Reporting
After each sprint, the Product Owner and other product development stakeholders receive a summary of the sprint, which includes a summary of delivered Product Backlog items, a sprint burndown chart, key decisions, identified risks and actions needed.
Our standards
Our coding standards
Our teams always follow coding standards to provide consistent, easy to understand and maintain codebase. Depending on the technology, we chose the best standards. Continually running forward, we’re implementing the best new solutions for our products - using reliable frameworks, tools, and trends in technology.
Definition of Done
Every functionality or change in the code we deliver meets the criteria listed in our definition of done, which assures quality and consistency in our delivery.
When starting a collaboration, we always agree what ‘done’ means. Our standard definition of done states, that a user story or bug from the Product Backlog is done when it is…
Peer code review
We have a code review process, which ensures every piece of code is reviewed and approved by at least one another experienced software developer. This approach, combined with continuous integration, automated tests, and other practices ensures the highest quality of the code and helps us to keep good programming practices in our software. This procedure is one of the most critical processes we practice, and we focus a lot of our attention on it.
Code metrics
We regularly check our code with automated tools to measure it against the crucial indicators of well-designed code: cyclomatic complexity, repeated code, test coverage, etc. We use tools like Sonar, Jenkins, Travis CI and our proprietary extensions. With these outcomes, we aim to improve our results by comparing data from reports and alleviating bottlenecks. Working with these tools allows us to achieve outstanding code coverage results.
Continuous integration
We use the Continuous Integration (CI) rule in our development practice. We merge the code frequently, which helps to avoid integration problems. We use leading platforms like Travis CI or Jenkins CI with a set of automatically generated quality reports of our code. This ensures us that only code which passes all the tests and quality meters will be delivered.
We use CI tools to schedule time-based and event-based automated test runs to regularly check for regression and provide immediate feedback to the team about actual code and quality status. These tools and our regular, scheduled, time-based regression tests help us to significantly improve our code quality and this is the first level of verification of code correctness.
Quality assurance
Depending on the particular business needs of the client, we prepare an individual plan to assure the delivered software is of the best possible quality.
To provide the best quality of the software we follow a comprehensive process as below.
The scope of testing
Depending on the product, we execute:
- Unit tests - individual units of source code are tested to determine whether they are fit for use.
- Functional tests - individual software modules are combined and tested as a group.
- Smoke tests - initial testing to reveal basic application functionalities failures.
- User interface tests - testing graphical user interface to design guidelines and mock-ups.
- User experience tests - measuring the degree of application usability.
- Regression tests - testing that verifies previous functionalities still work properly.
- Security audits - verifying application regarding the maintenance of data security.
- Performance tests - testing system performance, responsiveness, and stability under workload.
- Manual acceptance testing - checking if the requirements of the specification are met.
Dedicated Quality Assurance Engineer
Most of our teams contain Quality Assurance Engineer (QAE), who supports the team in test automation, delivering, maintaining and executing end-to-end regression tests, performing test scenarios, including acceptance and functional scenarios and executing tests strategies for future sprints. In many cases, it is crucial for the team to have such support to maintain best quality and stability of the product over time.
Our QA Engineers have proven experience and certified knowledge and take an active part in our quality assurance process. They provide immediate feedback regarding quality, giving the team enough time to react if any quality issues arise. Our QA Engineers not only produce automated tests but also work closely with all product stakeholders to assure all needs have been discovered and verified in code. It means analyzing business requirements and implementing the best solutions in line with them which is the fundament of creating high-quality applications.
Automated tests
In our work, we obey the following techniques and tools:
- Behavior Driven Development (BDD) approach to clearly translate business language into working code. We write acceptance scenarios using Gherkin notation, so it’s clearly understandable both for engineers and business - this way of preparing scenarios increases our transparency.
- Test Driven Development (TDD) approach in coding, for faster and easier detection of bugs in the initial phase of software development.
- Automation tools and frameworks to write functional tests, such as Selenium WebDriver, Protractor, Jasmine, Selenide, Appium, Sikuli and others, depending on product specification and target devices.
- To deliver the best matched and effective tests, we’re preparing test suites covering user stories from product backlog and other scenarios.
The excellence and quality
The process described above is the result of several years of experience, as well as our approach to the dev teams which is based on long-term relations and trust between all the people involved. It helps us create valuable software products for our clients, no matter if it is a long-term collaboration or MVP.
Nevertheless, at Boldare we put people and the relations between them before the process. That is why we always create software in collaboration with our partners. Software, which reflects client’s business needs and domain. Which helps our partners achieve their goals.
And this is exactly what Agile means for us.
Share this article:
