Chapter 25 — Team project studio
Lesson map
Lesson 25 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["25.1 The studio brief"]
N2["25.2 Dividing work"]
N3["25.3 Reviews"]
N4["25.4 Status communication"]
N5["25.6 Practical activity"]
N6["25.7 Working agreements"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 The studio brief"]
N2["25.2 Dividing work"]
N3["25.3 Reviews"]
N4["25.4 Status communication"]
N5["25.6 Practical activity"]
N6["25.7 Working agreements"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[25.1 The studio brief]
|
v
[25.2 Dividing work]
|
v
[25.3 Reviews]
|
v
[25.4 Status communication]
|
v
[25.6 Practical activity]
|
v
[25.7 Working agreements]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) work in a team to plan and execute a migration slice; (2) divide work by layer and dependency; (3) use reviews and shared evidence; and (4) communicate status clearly.
25.1 The studio brief
Teams of four take one KLS flow — partner SFTP, office VPN, customer API or internal mesh — and deliver a migrated lab replica with inventory, configuration, tests, monitoring, runbook and evaluation.
Each team gets the same constraints: lab only, synthetic data, the KLS profiles as the starting point and five weeks. The deliverable is judged as a whole flow, so a perfect configuration without monitoring or a runbook does not pass. Teams pick their flow in week one and cannot change it after the inventory is complete, which forces early decisions about scope.
25.2 Dividing work
Split by layer (network, platform, application, PKI) and by dependency: tasks that unblock others (lab environment, inventory) come first. Keep a shared board with owners and definitions of done.
In the SFTP team the lab and inventory owner finished first because the configuration work needed both; the client-matrix owner prepared test clients in parallel. The shared board lists each task with owner, dependency and definition of done, so a blocked task shows what it waits on.
When the client-matrix owner waited on a partner's test credentials, the board showed the dependency, and the SFTP team's 24-hour blocker-escalation rule (Section 25.7) moved the request to the partner manager at the next morning's stand-up.
25.3 Reviews
Every configuration change gets a peer review against the central profile; every claim in the evaluation needs evidence a reviewer can rerun. Reviews catch the misordered group list and the missing negative control.
Teams pair reviewers across layers, so the network specialist reviews the PKI owner's work and the reverse. A review comment must point at evidence, such as the rendered profile, a log line or a script output, and the author answers with a change or a reason. Reviews are tracked on the board with the date requested and answered.
25.4 Status communication
Weekly status: done, next, blocked, risks. Blockers name what is needed and from whom. Avoid percentage-complete figures that hide risk.
A blocker reads like: "Need partner client image v3.2 from the partner manager by Thursday; without it the matrix lacks two client types." Risks name what could change the plan. A report saying "70 % done" tells the reader nothing about whether the flow will be ready, so studio reports never use percentages.
Each risk is written with a trigger and a response, so the reader also knows what the team would do.
25.5 Worked example
Team "SFTP": week 1 lab and inventory (owner A); week 2 OpenSSH upgrade and KEX configuration (B); week 3 partner client matrix — six client types, two classical-only (C); week 4 monitoring and runbook (D); week 5 evaluation. Blocked in week 3 waiting for a partner client image; escalated to the instructor acting as partner manager; substituted a documented emulation.
The emulation was a reasonable substitute only because the team documented its limits: the emulated client used the partner's library version but not its proxy, so the evaluation marked results for that client type as lower confidence.
25.6 Practical activity
Form a team, choose a flow, write the plan and first status report.
Write the plan as a dependency-ordered list of tasks with owner, definition of done and the artefact each produces. Include the lab environment, inventory and trace, configuration, client matrix, monitoring, runbook and evaluation. The first status report uses the four headings done, next, blocked and risks. If nothing is blocked in week one, say what you expect to be blocked later and what you are doing now to avoid it.
25.7 Working agreements
Agree how the team will work before starting: how decisions are made and recorded, how reviews are requested and how quickly they are answered, how secrets used in the lab are stored, and what happens when someone is blocked for more than a day. Written agreements prevent the most common studio failures — silent blocking and unreviewed changes — and mirror how production platform teams operate.
The SFTP team's agreement set reviews within one working day and a blocker escalation after 24 hours.
25.8 Common errors and limits
- Everyone working on the same layer.
- Reviews skipped under time pressure.
- Status reports without blockers.
In one studio cohort a team of four all worked on the OpenSSH configuration in week two; nobody built the client matrix, and the evaluation had no data. Another team skipped reviews in the final week and shipped a profile with the hybrid listed second, the same misordering Lab T detects. A third reported "on track" every week until the deadline, without mentioning the missing partner image. Each failure is a process failure, not a technical one, which is why the studio grades process.
Exercises
- EX049 — Dependency order. Order five SFTP-team tasks by dependency and justify. Rubric: 3 = lab/inventory before config, config before matrix, monitoring before evaluation.
- EX050 — Status report. Write a status report for week 3 of the worked example. Rubric: 3 = done, next, blocked with ask, risks.
Synthesis
Studio projects practise team implementation: dependency-aware division of work, evidence-based reviews and clear status communication.
Continue studying — chapter 25 of 30
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →