Why use a software development process?

Gaining business agility



Defining a software development process should be the first step in a mid for long term software outsourcing collaboration between two business entities.


A process is a collection of related, structured activities or tasks that produce a specific service or product. It also serves as a protocol of communication between the parties involved in the collaboration.


By defining a collaboration process, parties will practically have a predefined ‘way of working’ in order to achieve business fluency. We generally opt for having a couple of meeting sessions with our customers prior to getting involved with the technical aspects of the solution, so that we may fully grasp our customers business scenario and needs.



Development methodologies



The most practical methodology for software development is the Agile methodology, which allows for iterative development cycles (two-three weeks) that offer the ability of fast pivoting or reorganization around the product’s core business scope. Whether our customers are a startup, or a company that has passed the incipient phase, the Agile methodology can be a great way to insure software development continuity.


At RED Abacus we try to start off with the Agile principles in mind, and tailor them to our customer’s specific business scenario. We call this a process calibration.



Process calibration

The process calibration aims to describe the exact collaboration protocol that we will use in the planning, development and shipping of deliverable components.

The aim is to:

  • Understand the business context of what’s getting developed and why
  • Define a strategy for structuring units of work, that is both business and developer friendly. This is very important, since the more business detail, the less time spent on implementation.
  • Agree upon how these units of work are managed. There are tools that satisfy this need, and we have experience with Atlassian JIRA, Asana , Rally
  • Establish a definition of done. This creates a mutual understanding of when exactly each unit of work should be deemed as complete. Ex.
    • Each unit of work should be developer implemented
    • Each unit of work should have unit tests
    • Each unit of work should have integration tests
    • Each unit of work should be manually validated by a QA
  • Establish iterations. These are practically sprints in which units of work get implemented
  • Establish meeting count and schedule (grooming, planning, retrospective)
  • Establish development strategy in order to meet deadlines

Business Analysis and estimation

Specification analysis and generation



A product is represented by a set of business features that it has to perform well in order for it to be relevant. For accurate estimations, we have to convert units of work into playable tasks for developer implementation, that can be easily tracked by both customer representatives and implementing team.


Right after the process calibration, we usually start something called a SPEC phase. SPEC stands for specification, and during this period, we try create a playable specification based on your requirements that should cover:



  • Detailed business scenario analysis

  • User story generation

  • Third party integration opportunities

  • UI/UX interaction planning

  • Data solution analysis

  • General software architecture design

  • Selection of a suitable tech stack




User stories


The units of work that are both business friendly and developer ready are called user stories. Practically, a user story is a single specific operation that a user can perform when using the system, and usually looks something like this:


As a normal user, I want to be able to login to the application using my personal credentials.


We use these stories in order to get a clearer understanding of what exactly should be developed, for each interaction case that a user may have with the ‘to-be-developed’ system.




Who needs this


We perform the Business Analysis phase for :



  • Customers with no technical background, that require software consultancy ( CTO as a service approach) for building the SRS

  • Customers that have a SRS, and require a proposal plus effort estimation for outsourcing work


Having a SRS will enable any software development company to estimate and implement the specified software solution.



Software consultancy

For customers who require technical consultancy, we start by having a series of product / business analysis sessions in order to further understand the scope of the solution. Based on a solid business understanding, we will perform a Feasibility Study and create a Software Requirement Specification (SRS), covering the following details:

  • Functional / Non functional requirements
  • Business analysis
  • Identified actors and use cases (+ user stories)
  • Proposed project architecture
  • Proposed tech stack (technologies used in implementing the product)
  • Study of infrastructural needs (such as cloud hosting)
  • Study of 3rd party integrations + costs

As mentioned, the SRS will cover User Stories, which we will use as guidelines for estimating playable effort. Practically, we’ll evaluate a scenario in which a user of the system can perform a single specific operation, and estimate the implementation’s complexity.

Software development

Estimations and quotes



For customers who already have a Feasibility Study or a SRS, and require an estimation for the effort of implementing the feature set for their proposed solution, we start by analyzing the business requirements and use cases, and provide estimates based on the effort required for each user story implementation, as described in the Business Analysis section.


After agreeing on a task management strategy we’ll populate the backlog with the playable user stories defined as part of the estimation effort and start implementing the features.



Embedded team members



For customers already having an agile methodology in place, whom only require software development work on predefined tasks, we’ll play the role of embedded team member. For this to happen, a couple of briefing sessions should be planned, so that the technical ramp-up be performed as fast as possible, giving us insights into:



  • Customer’s sprint cycles

  • Customer’s defined definition of done for units of work

  • Customer’s existent development environment scheme

  • Customer’s existent technical documentation (other than SRS)

  • Creation of all the necessary accounts, needed in the development phase

  • Code based practices and know-hows (how we do this, code style, code review strategy etc.)



Lets sync

Being a startup ourselves, at RED Abacus we encourage a culture of development and growth, and are always eager for having exposure to new and exciting projects.

This website uses cookies.