DATED: 15-Jan-2021 Software Development Process

VERSION: 1.3 CREATED BY: Shahid Rafi

 

PROCESS OWNER: PMO

 

LAST UPDATE: 04 – Mar – 2021 LAST UPDATED BY: Shahid Rafi

 

I. INTRODUCTION

The software development process provides guidelines to achieve higher performance and
improved quality. By using an optimum SDLC, software developers can create robust functional
systems. It begins from the requirement gathering and ends at deployment.

Software development is a challenging and complicated process. But with the help of software
development experts and using asuitable software development process, we can have error free
solution / builds and ensure on-time delivery.

After observing the needs and issues faced by teams & resources, I came up with a tailor made
process. Instead of using typical waterfall OR Agile methodologies, I came up with a Hybrid
process, that can suit best for our needs and help us in resolving our issues / concerns. The
suggested Hybrid framework is a mixture of the Waterfall and Agile Methodology combined to
follow sequential flow for Requirements and Design and then iterative cycles for the Development
process. In this hybrid process the idea was to combine the benefits of both software development
models which aids in business values with the precision of the waterfall model and speed of the
agile model combined.
II. PROCESS STEPS
a) Leads Handling and Pre-Sales
Even before the pre-sales process, the Customer Success Manager (CSM) will engage
customer, sending a greeting email, with our company profile and describe the different models
that we offer e.g. Time & Material, Fixed cost etc.
We need to explain and educate the customer for Pros and Cons of different models. Like in
case of Fixed cost & Fixed time project, we need to spend decent time in the analysis and
design phase, so that we can build a solid understanding over the requirements and can come
up with a detail estimates and timelines.

If the customer has brought a simple idea or raw requirements, our team will be involved for
reviewing the idea, refining the requirenents, suggesting technology stack and calculating the
ballpark estimates. These ballpark estimates will be shared as a range of optimist and passimist
estimates, along with the %age of confidence level of team, on the clarity of shared
requirements. i.e. Less clarity means less confidence level, which can result in high variance
%age from the initial estimates.

For fixed cost / fixed time projects, a paid Analysis and Design activity is recommended. It is
very important to know the exact requirements and expectations of cutomer before calculating
any estimates. On the other hand, after having this session, team will be in a much better
position to estimate and calculate required resourcesa nd timelines, without having much fear
of unforeseen risks. Therefore, this activity is useful and helpful for both, team as well as
customer. This initial Analysis and Design activity can be done in two ways:
i. 4 to 6 weeks Analysis and Design phase, in which PO/BA and architect, will conduct
interviews with stakeholders and create a comprehensive SRS document. Also will
suggest the teachnology stack and required resources for the project.
OR
ii. We can have a 3 to 6 weeks Deign activity, in which the team members will
aggressively work with client, understanding requirements and come up with UI/UX
designs, application flows and/or prototype. PO/BA, architect, UI/UX and couple of
experienced developers will be involved in this activity.

This activity will be a paid activity, mutually decided with client beforehand. If client decides
to continue with us for development / implementation, this cost may get waived off, otherwise,
client can pay for this activity, get the decided deliverable (requirement document,
wireframes, technology stack, ballpark effort and cost estimates, etc.) from us and close
the project at this point.
On the basis of our findings, a requirement document will be created. The Customer has to
sign-off / approve the requirement document.
Only Solution Architect, PO / Requirement Analyst to be involved in the pre-sales phase.
 While for Time & Material model, we will follow Agile methodology. PO / Requirement
Analyst to write down SRS, refine and prioritize the user stories with the help of client. Norgic
will provide complete transparency to the stakeholders for this model through regular
meetings, reports, ClickUp etc.

We will try to keep our team as minimum as possible in this phase. For Design and Analysis
activity the team will be formed on need basis, as accepted and approved by client.

b) Initiation | (After Contract Signed-Off)

After the approval and acceptance of proposal, ballpark estimates and timelines, the client
needs to sign the contract to move ahead in the project. The PO will finalize the SRS artifact
and then create (OR refine the already created) user stories. PO will also prioritize the PBIs.
Then the PO / Requirement Analyst will conduct a requirement understanding session with the
team.
In case of Time & Material contract and Agile model, we can start with a partial SRS, i.e.
requirement details for some high priority features and move to relevant requirements and user
stories to Design and development phases, while the PO will write the remaining SRS in
parallel to development of already shared SRS features.

Input:  Signed Contract, SRS / Stories

Output:  Prioritized PBIs, Refined stories

Resources:  PO, Architect

c) Design Phase
PO + Architect + Leads will finalize the design and architecture of the required soluton and
create a technical specification document. In Time & Material model, this design and
architecture will based on the available partial information, we may need to modify / update
the design upon receiving the remaining requirements / details. This can be achieved in sprint
zero.
A cross functional team will be compiled against the required stuff.

Input:  SRS, refined PBIs

Output:  Design / Architecture artifact, Cross functional team

Resources:  PO, Architect

d) Impact analysis session

An impact analysis session is suggested at this level, to bring all the team members on the
same understanding of requirements and it’s proposed solution. Any possible impact on any
other part of the code / system should be discussed and handled in this phase. The solution /
technical specification document may be updated after this brain storming and discussion
session.

Input:  SRS, refined PBIs, Technical specification document

Output:  Common understanding, updated technical specification document,

finalized (with consensus) solution

Resources:  PO, Architect, team

e) Estimation and Planning
PO & Lead will conduct an estimation and planning session. The designated team will take
part in this activity. Planning poker or some similar approach is highly recommended. This
way the whole team is involved and will have common understanding about requirements /
stories, team members will also feel the ownership. Team with the help of Leads & Architect,
will also break down the stories into smaller stories or tasks, so that these stories / tasks can be
assigned to developers for dev work.

Input: SRS, Prioritized User Stories with acceptance criteria, Technical

specification artifact

Output:  Sprint backlog, WBS / Tasks, estimates

Resources:  PO, PMO, Team

f) Sprint
After the estimation and planning, the sprint backlog is finalized and scope of the sprint is
fixed. We will take a snapshot of the Figma / screen designs and/or requirement document
version for the current sprint. Leads & Team members will split the stories in smaller tasks.
Ideal size of tasks should not be more than 16 hours, these small tasks will be delivered to QA
on regular basis during the sprint, so QA will have reguler small chunks for testing, instead of
wait till the end of the sprint duration.

The QA team members will write Test cases basis on the requirements discussed, understood
and finalized for this sprint. These test cases can be shared with developers, to confirm the
understanding of expectations on both sides.

In the execution phase, team members will pick items from the Sprint backlog, with mutual
consent. Team members will share the work progress and/or any impediments in the daily
scrum sessions. ClickUp needs to be updated on daily basis as well.

Each task needs to be code reviewed before checking in (on each Pull Request), Senior
developers or Architects will conduct these reviews and document the review outcome as well.
The reviewers will act as coach and mentors to developers,
These code reviews will help in improving the code and deliverable quality and reducing the
QA cycle time. This CR review data will also be used for training / couselling needs of team
members. No ticket shall go to Testing without passing the Code Review. The reviewer to add
comments on clickup ticket regarding the conducted and passed CR i.e. CR done by: ???,
dated: ??? etc.
 Input:  Prioritized User Stories, Acceptance criteria, Technical specification
artifact, Tasks, Estimates

Output: Working software build

Resources:  PO, PMO, Team

g) QA / Testing
QA / Testing team will perform the testing on the developed tasks during the sprint duration.
Bug fixes and verification will also be done during the sprint duration. Time required for this
bug verification cycle needs to be taken care in the planning session, with mutual consent of
the team.
Quality is team’s responsibility, so the team will work on development and testing together.

Input: Dev completed and Code Review passed stories,

Output: QA Passed stories, Updated ClickUp stories

Resources:  Team
h) Backlog Grooming
Backlog grooming session is recommended on weekly basis, so that Backlog items are
updated, organized and prioritized. PO can add or modify the PBIs during these grooming
sessions.
Input: Backlog

Output: Prioritized PBIs, Updated Backlog

Resources: PO, PMO, Team

i) Sprint Review
At the end of each sprint the team will conduct a sprint demo and review session with PO and
other stakeholders. The developed features will be demostrated and reviewed by PO. Only
accepted / approved features will be shipped as the release while the others will be sent to
Backlog for future sprints.

Input:  Sprint Backlog, Developed Build (Completed stories only)

Output: Accepted / approved build, Spillovers, Updated Backlog

Resources:  PO, PMO, Team

j) Retrospective Session
After concluding the sprint, a retrospective session will be conducted by the team. Only team
members will attend this session. It will not be a blame game session, rather team will talk
about the things that went well and also mention about the things that can be improved. Team
will also suggest the action items required to make improvements. Lessons learned from this
session will be used to improve things in future sprints.
Input:  

Output: Retro document, Lessons Learned, Action Items

Resources:  PMO, Team