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.
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.
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
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.
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
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.
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.)
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.