Stan Sakharchuk June 2, 2020 / 184 views

We’ve already spoken about the first two steps of the interexy development process – Step I (Specification & Estimation) and Step II (Design Development).

Here comes the time of the most major and one of the most influential parts of any app – app development.

Despite the fact our specification development process is a bit Waterfall-ish, we’re following Scrum through our development process. And there is also a reason why we do specs – most of our projects are from scratch & don’t have any specs, documentation, tech product plan, etc. – that’s a necessary part of any MVP development due to the importance of business analysis & tech analysis and concept validation.

So how do we structure our development process? How we make sure clients know at each point of time what’s happening with the product, what kind of issues we’re solving atm, what kind of blockers do we have & do they see the relevant version of the product? Weekly calls are a default part of our process – we have special agenda for each of them depending on the position of the call within the sprint. If it’s the start of the sprint – we’re presenting what’s planned to accomplish for the sprint, summing up feedback & backlog from the previous one and making sure we’re moving smoothly according to the timeline.

In case the call is at the end of the sprint, we prepare a presentation session of the latest version of the product with everything that was added/fixed during the sprint. The goal of the call is to make sure our clients are on point with the current product status, showcase functionalities & do a bit of feedback gathering and planning for the next two weeks period.

We’re also using software for project management & planning, usually, it’s Trello or Jira or Asana. Trello board illustrates everything that’s planned for the sprint, possible blockers that’ll have soon, what exactly are we working on now & what’s going to be finished at the end of the current sprint. The main goal for the project management software from the client’s point of view is being able to see in real-time what happening with the project at any time. It improves communication & solves the status update issue.

Inside the team, we’re following the default Scrum process – daily standups, revisions, QA, revisions, working on the feedback & planning next sprint.
We also have weekly code reviews inside the team members & from our team leader. This helps us to follow best practices during the development, provide sustainable & quality architecture and make sure it’ll be easy to pick up the product from any part of its functionality.

The process might look pretty simple & straightforward – we’re able to not overcomplicate it due to extensive pre-development & pre-design work.