How a Software Development Team Actually Works

Full disclosure up front: I've spent the last few years in fintech, so my view is a bit "tinted" by the industry. Today I'll break down how a software development team is structured — from gathering requirements to release: the phases the work goes through and who owns what.

Phase 1. Gathering Requirements

1. The Business Analyst (BA) researches the market (for an external project; for an internal one this step usually gets skipped) and user needs, shapes an initial vision of the product or feature, and hands it off to the Product Owner (PO).
2. The Product Owner (PO) defines business value and priorities, fills out and refines the product backlog (User Stories, tasks), aligns requirements with stakeholders, and syncs with the Tech Lead.

Phase 2. Planning and Analysis

1. The Systems Analysts (SA) drill into the requirements, work through the technical aspects and constraints, and prepare the specs and documentation.
2. The Scrum Master runs sprint planning, helps clear blockers, and keeps the process inside Scrum (or one of its offshoots).
3. The Tech Lead and developers hash out how to actually build it, estimate the complexity of the tasks, and take part in sprint planning.

Phase 3. Implementation

1. Developers take the finished spec from the SA, write the code, and run it through code review.
2. DevOps sets up the environments and CI/CD pipelines, handles the infrastructure, and takes the routine off the team's plate through automation.

Phase 4. Testing and Iteration

1. QA writes test cases, runs functional, regression, and load testing (there can be plenty more kinds), and files the bugs they find.
2. The whole team gathers at daily standups: they talk through progress, dig into the problems that come up, and run sprint retrospectives.

Phase 5. Demo and Retrospective

1. The PO and BA (sometimes the Tech Lead and SA) accept the work, check it against the requirements, and set up a demo for the interested parties.
2. The team runs a retrospective and discusses what to improve in the process.

Phase 6. Release

1. DevOps and QA prep and run the deploy to prod and keep an eye on the product's health after the release.
2. The PO talks to clients and users and collects feedback once it's out.

This is just one slice — a snapshot of the process at a single moment. In real life it drifts: it depends on the team's methodology (Agile, Scrum, Kanban), its makeup, the industry, the specifics of the project, and a dozen other factors. The key thing here is the living interplay between everyone involved and flexibility: the ability to adapt to changing requirements and conditions.

Have a good Friday))

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP