Team Brilliant

SDLC

The delivery lifecycle a pod runs, from inception to release, and what each stage has to produce.

01 layer

governance

the limits it cannot cross without a human

03 playbooks

stands on its own

04 next

end of the chapter

The software development lifecycle is how a change gets from an idea to production: developed, tested, operated, reviewed. Written down, it is what lets a team produce reliable software predictably rather than heroically.

Getting it streamlined is hard, and most of the difficulty is not in the stages. It is in the team structure and the role definitions underneath them, where the details that break a process are not visible until they break it.

Reading the board

Work starts in the top left and the job is to move every ticket to the top right. The board divides into eight areas, and four of them are the ones worth arguing about.

1. The stages themselves. The columns a ticket passes through on its way to the top right.

2. Preparation for active work. An engineer takes the top ticket off the list.

3. Assigned and ready for development. Tickets pre-assigned before anyone starts them. Avoid stacking work here at the start of a sprint unless there is a specific reason for it, and make sure the reason is the team's rather than one person's. Pre-assignment decides on Monday who will do work on Thursday, which is a decision nobody has the information to make yet.

4. Active work. Tickets in progress, in development, in QA or in acceptance, each assigned to an individual. When you finish your part, move the ticket to the next state and unassign yourself.

5. Queued between stages. Unassigned tickets waiting to be picked up. A ticket in QA with nobody assigned means the next available QA engineer takes it when they finish their current one. This is the area that makes throughput visible: if it is filling up, you have found your bottleneck.

6. Done and still assigned. This should be empty. Once product has accepted a ticket there is no work left on it, and leaving your name attached keeps it on your radar for no reason.

7. In development and unassigned. This should also be empty. Development is active work and implies somebody is doing it. If nobody is, move the ticket back to ready for development so the board says so.

8. Done. Tickets that went through the whole lifecycle and were accepted.

How a ticket moves

The rules that keep the board honest are the small ones. Do not pre-assign. Unassign when you hand off. Never let a ticket sit in development with nobody on it. Each of those sounds like bookkeeping, and together they are the difference between a board that reflects reality and a board that everyone has learned to distrust.