HOW WE WORK
We maximize chances of entrepreneurs to build successful products.
ONBOARDING NEW CLIENT
We want to make the communication process between the Client and us as easy as possible. Early on in the process, the Client will receive a welcome mail with Onboarding Document. In that mail, the Client will also find essential information related to the assignment. Our Product Owner will introduce the team through the mail. Product Owner will add Team Members to communication channels unless agreed otherwise.
Our Product Owner will schedule a kickoff meeting, Sprint Reviews, one-to-one meetings – to discuss the context and success metrics.
Before meetings, our Product Owner prepares the agenda for each one, so the meetings are productive. All meetings are video conferences, but there is a possibility to run some of them face to face. The latter option is discussed directly with the Product Owner.
When the Onboarding process is complete, our Product Owner will contact the Client with the request of the feedback for it. Once a quarter Client will be asked to fill the NPS survey. We want to establish a Customer Feedback Loop that leads to constant product improvement. Our Product Owner meets with the Client as frequently as there is a need to discuss short and long term goals, feature specification, roadmap, or any other business.
OUR PRODUCT MANAGEMENT FRAMEWORK
Agile software development
We use agile framework – Scrum. Our development team consists of 5 to 10 people. They are multidisciplinary, customer-focused, and led by the Product Owner. They are always going for better, faster, simpler, pragmatic solutions. Continuously and proactively suggesting changes in the requirements that maximize ROI.
Large Scale Product Development (LeSS)
For larger engagements, we work in teams of 10 people that are delivering value independently. We scale product development with the LeSS framework. Scrum teams with a common goal to deliver the shippable product at the end of the common sprint. Teams are led by Product Owners and supported by Servant leaders.
We promise our customers that they will go live with their product in less than three months (6 sprints). You and we need to listen to your target audience. The sooner we get feedback, the more time and money you will have to improve your product. And the best way to collect feedback is through a working product—time to market matters.
PRODUCT DEVELOPMENT MEETINGS
Sprint planning sessions with the Client’s team (once a sprint). Up to 2 hours. Once two weeks.
Daily standups with developers team and Client’s team if needed. Up to 15 minutes.
Backlog refinement meetings with the Client’s team (once a sprint). Up to 1 hour.
Retrospection session within the development team, usually without client representatives (unless required). Up to 2 hours. Once two weeks.
Review sessions at the end of each sprint presenting the deliverables of the cycle, Client’s team is required to be at this meeting. Up to 3 hours. Once two weeks.
Joint Slack channel between Client’s team and developers.
We continuously want to improve our relationship with the Client and address potential issues not exposed during the day to day collaboration. The meeting takes place quarterly between our and the Client’s management representative.
High-level estimation process
We are estimating and forecasting features to prepare product roadmaps. The repeatable process executed every 2-3 months when the Client’s organization needs it. The process involves both the development team and client representatives.
Half-yearly review of the Client’s expectations of our services and defining future improvements of them. The meeting happens between Pragmatic and Client’s management representative.
After signing up an agreement and gathering crucial requirements, we will set up a project vision together with the Client and report it to all stakeholders and our development team.
At the beginning of work, we will report to the Client the product development plan, MVP scope, expected outcome – what product value we undertake to deliver. What we report depends on gathered information about the main functions, technology, product-market fit, legal requirements, etc. We always adapt to your business.
During the product development, we report to all stakeholders crucial information about the health and condition of the project and what we should do to avoid/minimize/eliminate risks. We report the project performance against budget and timeline. Verification and validation of business case/purpose and topicality of MVP. The current value of a developed product – e.g., conversion rate, customer acquisition, revenue, cost savings, customer retention. These reports will be sent regularly once a month or more often (if needed, e.g., on-demand at the end of the sprint).
Issues and risks/blockers
At the end of each sprint, we report to the Client, the summary of implemented epics/features, and what we have not done yet, what was a reason for this situation and what we would like to improve to avoid similar situations in the future? We also report what changes appeared during the sprint, and what is the plan for the next sprint. The Client must accept all changes before adding them to the sprint.
During the whole development, Pragmatic Coders regularly communicates with clients to ensure high quality of work and feedback loop.
CODE REVIEW STRATEGY
About code review
At Pragmatic Coders, unsupervised code changes are not achievable. We follow best development practices, so our products are robust, code maintenance is easy, and our Clients’ satisfaction is at the highest level. All our teams have adopted fundamental code review principles and understand that change in the code is a responsible task. It does not matter if a person is an author of the very first change in the rising project or person is making core updates in the system on production – we follow the same rules.
Technical Excellence level during the review strictly depends on the part of the software. If this is the core of the system, we take no prisoners; no corners are cut.
The code review process
Every code change results in a separate branch with a merge request.
When a developer creates a merge request, it is required to deliver descriptive title, description, and reference to issue tracking software.
The first review is performed by CI/CD environment tests, next it has to be reviewed by at least one developer who is proficient in the field of the proposed change, before merging to the master branch. When Code Review is completed, change is rebased with the master branch, and commit is aggregated.
We use a fully automated CI/CD environment that builds, tests, and deploys newly promoted code. The author of the change is responsible for tracking the progress of the pipeline and is the first person to take action if any part of the process is malfunctioning.
Key values that the code reviewer follows
The code needs to comply with the current architecture setup.
Change needs not to break any principles or frameworks used by the component (like SOLID principles, Hexagonal architecture, Domain-Driven Design, etc.). Functionality needs to be placed in the right component.
Abstraction is well thought and can be used later, over-engineered solutions are not welcome. The cost of maintaining the solution has to be minimal; Any potential errors need to be able easily found on production. Change doesn’t compromise component performance. Naming conventions follow ubiquitous language used by the business and developers. Tests check the functionality and follow the principles of Test Pyramid.