How a Software Development Team Actually Works

I have spent the last several years in fintech, so this model is closest to the large product and enterprise teams I know. It is not a universal org chart. The stages overlap, and one person may cover more than one role.

Phase 1. Discover the problem

1. The Product Owner (PO), Business Analyst (BA), and other product roles explore the problem, the users, the current process, and the expected outcome. Internal products need discovery just as much as customer-facing ones do.
2. The PO is accountable for product value and ordering the backlog, while keeping stakeholders aligned on direction. The exact boundaries of the role vary by organization.

Phase 2. Planning and Analysis

1. Systems Analysts refine scenarios, data, integrations, constraints, and quality attributes. The output might be a specification, diagram, API contract, or another artifact the team can use.
2. The Tech Lead and developers assess implementation options, risks, and effort. QA, platform, security, and other specialists should join early when their constraints shape the solution.
3. In Scrum, the Scrum Master is accountable for establishing Scrum and helping the team improve its effectiveness. They ensure events take place and remain productive within their timeboxes; they need not personally chair every meeting. Kanban and other operating models distribute those responsibilities differently.

Phase 3. Implementation

1. Developers build the solution, write automated tests, review code, and continue refining details with analysts and product colleagues. A strong specification reduces uncertainty but does not remove the need for conversation.
2. Platform, infrastructure, or DevOps engineers may support environments, CI/CD, observability, and automation. DevOps is also a set of shared practices, not merely a job title or a handoff point.

Phase 4. Verify quality

1. QA helps shape the quality strategy, designs checks, automates tests, and explores risky scenarios. Performance, security, and reliability receive attention in proportion to the product’s risk.
2. Quality work does not begin when coding ends. Acceptance criteria, testability, and observability are considered early, with checks running throughout delivery.
3. In Scrum, the Daily Scrum helps developers inspect progress toward the Sprint Goal and adapt their plan for the next day. It is not meant to be a status report to a manager; the retrospective is a separate event at the end of the sprint.

Phase 5. Demo and Retrospective

1. The team checks the increment against its acceptance criteria and Definition of Done. A demo shows the result and invites feedback. A Sprint Review goes further: the team and stakeholders inspect the Sprint outcome, changes in their environment, and possible next steps, adapting the Product Backlog as needed.
2. The retrospective focuses on how the team works. It should produce a small number of improvements that can be tested in the next iterations.

Phase 6. Release

A release need not wait for a demo or the end of a sprint: a usable increment can be delivered earlier. The Sprint Review is not a mandatory release gate.

1. Release is a team responsibility. An automated pipeline, monitoring, a rollback plan, feature flags, and a clear response process reduce delivery risk.
2. After release, the team monitors both system health and product outcomes. Product roles gather feedback and adjust priorities based on evidence.

Role names and ceremonies are secondary. What matters is that the team understands the goal, gets feedback quickly, manages risk explicitly, and owns the path from an idea to a measurable production outcome.

A vertical slice in practice

Consider an illustrative feature: customers should see their application status. The work does not end with a screen. The team needs a source of status, freshness expectations, access rules, and behaviour when the source is unavailable.

The analyst clarifies states and transitions, an engineer proposes data access, QA explores errors and delays, and operations helps define observability. These activities overlap. Passing work strictly between departments can reveal an important constraint too late.

The first complete slice may support one application type, but it should cover the source, API, interface, permissions, validation, and post-release observation. That creates product feedback. A finished interface without data tells us much less about a working solution.

Who decides when constraints conflict?

Shared responsibility does not mean an unnamed “team” makes every decision. Product priority, implementation, and acceptable risk need different authority. Leadership should make these boundaries visible early.

When time and scope conflict, show options: narrow the first scenario, defer features, change the date, or bring in missing expertise. “Do the same work faster” needs a basis. Quietly cutting validation transfers the cost into operations.

To improve the process, I would inspect where changes wait: for a customer answer, access, review, a test environment, or a release window. Address that constraint; otherwise new rituals merely add meetings.

Scrum accountabilities and events are defined in the official Scrum Guide. The model here is broader: it is how I discuss the product lifecycle and participants’ responsibilities.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP