Development Team

When work was organized by discipline, a single feature passed through several teams. Product wrote a document, design drew the screens, engineering turned that into code, and quality checked it at the end. Each team finished its stretch and handed the work on.

The trouble showed up at every handoff. Drawing screens surfaces cases the document never covered, and by then whoever wrote it had moved on to something else. Writing code hit the same wall. When a late feature triggered a meeting, "we handed our part over on time" went around the table, and each person was telling the truth about their own stretch. Nobody owned the feature end to end.

Development team is the line redrawn to erase those internal borders. Instead of grouping by discipline, it names everyone required to produce one finished result as a single team. That means it isn't only engineers. The person drawing the screens and the person checking quality are on the same team, and whether something usable came out of the cycle is judged as that whole team's result. The word "development" invites the narrow reading often enough that newer writing tends to call the group the builders instead.

The day opens with a 15-minute daily scrum, and the rest of it goes into finishing items from the sprint backlog one at a time. The sprint backlog is the set of work chosen for this cycle, and as a rule nothing outside it gets inserted partway through.

1. Fifteen minutes in the morning. What finished yesterday, what's planned today, what's blocked. It's not a status report to a manager but a way for the team to line up the day. When a blocker comes up, nobody solves it on the spot — they agree on who looks at it and when, then move on. That's what keeps it to 15 minutes.
2. Take one item and carry it all the way to the definition of done (DoD). The definition of done is the standard the team wrote down in advance for calling something finished — usually passing code review, tests running, and running in production. Work that doesn't reach it counts as nothing this cycle, even at 90 percent.
3. Look at other people's work. A team where everyone only pushes their own items ends up with a pile waiting for review on the last day. Many teams set aside about half an hour each morning for this.
4. Surface blockers the same day. Waiting on another team's answer, or being stuck without access, doesn't resolve by holding on to it quietly. Clearing that kind of obstacle belongs to the person who tends the process, not to the team.
5. On the last day of the cycle the team demonstrates what it built at the sprint review, then picks one or two things to change in the retrospective that follows.

Five to nine people is the size usually recommended for one team. Fewer and the skills needed aren't all inside the team, so requests go outside more often. More and not everyone can speak inside those 15 minutes. At around twelve, teams usually split in two.

Two roles sit where the team meets everything outside it: the person who decides what gets built first, and the person who keeps the process working.

The product owner has the final say on the order of the backlog. What comes first is their call; how it gets built and how much fits in a cycle is the team's. Blur that line and it breaks in one of two directions. Let the team set the order and the technically convenient items go first. Let the owner dictate the method and the team turns into a group taking dictation.

The scrum master is not a manager but the person who removes obstacles. They chase down the answer another team owes, get access that's missing, and push back when work tries to cut into the middle of a cycle.

At the end of each cycle the team meets the people who come to see the result. At Pagedeck, Sofia sits in on the review to check whether what was promised to customers is there, and Grace to see whether the quarter's goals are within reach. Feedback from that room doesn't disturb the current cycle; it goes into the list for the next one.

"That's the development team's call. We decide the order."

Redrawing the line between what gets built first and how it gets built.

"There's no designer on the development team, so every screen check has to wait on someone outside."

The disciplines needed aren't all inside one team, which turns into waiting time.

"Looking at where the development team is this cycle, 40 is a stretch."

The plan is above what the team has actually been able to absorb.

Back when Pagedeck had thirty people, six engineers formed one team and both design and quality checks sat outside it. Every time an undefined case turned up mid-build, someone filed a request with Noa and waited two days. Four or five of those waits per cycle meant the final two days always went to catching up.

Theo counted the waiting and brought the number to a retrospective: three and a half days across two cycles. So Noa moved into the team, and quality checks came with her. The morning 15 minutes went from six people to eight, but an ambiguous screen got settled on the spot instead of two days later.

The most common mistake is reading the name as engineers only. Plenty of companies do use "development team" as the name of the org where the engineers sit, which makes the reading natural. In scrum it means everyone needed to produce the result. Designers and quality people are on the same team. Put only engineers in it and the handoff structure the term was meant to dissolve comes straight back — checking one screen means filing a request outside again and waiting two days.

The other mistake is treating it as a group that builds whatever it's handed. Because someone else sets the order, it looks that way. But what gets decided outside stops at what comes first. How to build it, and how much to take on this cycle, belongs to the team. Set the volume from outside too and the team loses any grounds for saying no. Two or three cycles of that and unfinished work rolling forward starts to look normal.