Demo day and retrospective

On Friday 18 December the team presented Ridgeline Ops in the roastery, with coffee from the first subscription batch. The audience was Rosa, the staff, Lena, and the instructor from Sam and Nia's college program, who would grade the capstone. Ten minutes of demonstration, ten minutes of questions, then a retrospective with just the team. This lesson covers how they prepared a demo that told a story, how they measured the project against the success measures from lesson 1, how they ran the retrospective, and how each of them turned the project into a portfolio piece and a story for job interviews.

It is also the end of the Python Programming program. The last section looks back at what the program covered and forward at where you can take it.

Plan the demo as a story

A demo is not a tour of every screen. The team built theirs around one subscriber's journey, the persona from lesson 1, because a story is easier to follow and remember than a list of features. Priya signs up at the cafe with Mei; the morning renewal job creates her order; Theo packs it from the tablet; she skips a delivery from her phone during night shifts; the report shows her revenue on the right day for Anita. Each step showed one user getting one job done, and each was introduced by the person whose job it was: Mei demonstrated the sign-up herself.

The team planned the ten minutes to the minute, wrote the plan down and rehearsed it three times. The first rehearsal ran seventeen minutes. They cut the stock-check walkthrough to a single screenshot, moved the architecture overview to the questions in case anyone asked, and dropped a feature, the CSV export, that worked fine but did not serve the story. A demo that runs long gets rushed at the end, which is exactly where the strongest part usually is.

def plan_demo(segments, limit):
    names = [name for name, minutes, priority in segments]
    return names, sum(m for _, m, _ in segments)

SEGMENTS = [
    ("Problem and users", 1, 1), ("Sign-up at the cafe", 2, 1), ("Morning renewal job", 1.5, 1),
    ("Packing on the tablet", 1.5, 1), ("Skip from a phone", 1, 2), ("Stock check walkthrough", 3, 3),
    ("Daily report", 1, 2), ("CSV export", 1, 3), ("Results so far", 1, 1),
]
print(plan_demo(SEGMENTS, 10))

Prepare for things to go wrong

Live demos fail in front of audiences with remarkable reliability. The team prepared as if they would. They demonstrated on staging, not production, with a dedicated demo subscriber and a fixed date set through the injected clock from lesson 6, so the renewal job would create Priya's order on demand rather than at 6:00 the next morning. They checked the roastery's Wi-Fi the day before, brought a phone with a mobile hotspot, and recorded a screen video of the whole demo as a fallback. Each person knew the other's segments well enough to take over.

Something did go wrong: the tablet Theo used for the packing segment had installed an update overnight and logged him out. Because the team had rehearsed the fallback, Nia switched to her laptop showing the same page within twenty seconds, and the audience barely noticed. The lesson was not that demos are dangerous; it was that preparation turns a failure into a footnote.

Show results, not only features

The strongest part of the demo was the last minute, when Jordan showed the project against the success measures Rosa had approved in the first week. Features show what was built; results show whether it mattered. He was honest about what was met, what was not yet measurable and what was missed, and he showed the evidence for each.

Showing the missed item was deliberate. Rosa already knew, because it had been decided openly in sprint two, and listing it showed that the team managed scope rather than hiding it. The college instructor said afterwards that this table did more for the grade than any single feature, because it showed the team understood what the project was for.

def report(measures):
    lines = []
    for m in measures:
        lines.append(f"{m['name']}: met (actual {m['actual']}, target {m['target']})")
    return lines

Answering questions

The ten minutes of questions tested the team as much as the demo. The team had listed the questions they expected and agreed who would answer each: Jordan for scope and priorities, Sam for deployment and security, Nia for the staff pages and testing. Kai asked whether the roast plan could include wholesale orders; Jordan explained that it was on the Later list and what it would take. The instructor asked why they had chosen SQLite, and Sam answered in two sentences, then offered to show the decision record. Anita asked what would happen if the renewal job failed on a holiday morning, and Nia walked through the heartbeat alert and the runbook.

Two habits made the answers good. The person answering repeated or rephrased the question first, which gave everyone time to think and made sure the right question was being answered. And when the team did not know something, such as the exact cost if subscriptions grew tenfold, they said so and promised a written answer by Monday, then delivered it. An honest I do not know yet, followed by a real answer, earns more trust than a confident guess.

What happened next

The project did not stop at demo day, because Ridgeline Ops was real. Over the holidays, subscriptions became a popular gift; the web shop added a gift option in January, built by Jordan in two days on top of the existing services. Four-weekly deliveries, the story cut in sprint two, shipped in February. The single SQLite instance comfortably handled the load, and the decision record's trigger for moving to PostgreSQL had not been reached by the spring. Rosa started the charter for the wholesale portal using the same one-page template, with Jordan leading and a new co-op student joining the team.

The retrospective

After the guests left, the four of them, with Lena facilitating, held the last retrospective of the project. The weekly retrospectives had been short and focused on the next sprint; this one looked at the whole term. They used a simple format: everyone wrote sticky notes in silence for ten minutes under three headings, what went well, what was hard, and what we would do differently, then grouped similar notes, voted with three dots each on the most important groups, and discussed the top ones. Writing in silence first matters, because it stops the most confident voice from setting the agenda.

The top items were revealing. What went well: the charter's out-of-scope list, the work-in-progress limits, the contract tests and the testing session with staff. What was hard: the first sprint's underestimate, the time zone bug and the leaked key. What they would do differently: set up continuous integration and deployment to staging in the first days rather than the first sprint, test with staff in week two instead of week four, and estimate infrastructure work as stories instead of hiding it.

A good retrospective ends with a few concrete actions with owners, not a list of feelings. Because the project was ending, the actions were for the people and for Ridgeline: Jordan would run a staff testing session before every major release; Sam and Nia would set up pipelines first on their next projects; Rosa would keep the charter habit for the wholesale portal. The team also did something retrospectives often forget: they thanked each other for specific things, and Theo, Kai, Mei and Anita for their time.

def top_groups(notes, votes, n):
    counts = {}
    for v in votes:
        counts[v] = counts.get(v, 0) + 1
    return sorted(counts.items())[:n]

Turning the project into a portfolio piece

A capstone that lives only in a private repository does little for your career. Each team member wrote a case study: a page or two describing the project for someone who has never heard of Ridgeline. A good case study follows the same arc as the demo: the problem and the users, your role, the key decisions and why you made them, the hardest problem and how you solved it, the results with evidence, and what you would do differently. It includes a few screenshots, a diagram, and links to code samples that show your best work, with permission from the business if the repository is private.

Be precise about your own contribution. Employers know capstones are team projects, and they will ask what you personally did. Nia's case study said she built the staff pages, ran the accessibility testing and wrote the staff guides, and that she paired with Jordan on the roast plan export. That is far more convincing than claiming the whole system. Never present a team's work as yours alone; interviewers often ask follow-up questions that expose it, and honesty about collaboration is itself a strength they are looking for.

In interviews, the STAR structure turns project experience into clear answers: the Situation, the Task you were responsible for, the Action you took, and the Result. Asked about a time something went wrong, Sam told the leaked key story: the situation (a key committed in the first sprint), his task (he had committed it), his action (revoked and replaced it the same day, then added secret scanning to the pipeline), and the result (no exposure found, and no secret committed since). Owning a mistake and showing what you learned from it is one of the strongest answers a junior developer can give.

Looking back at the program

The Python Programming program started with print statements and variables in PYTH-101 and ends here with a deployed, secured, documented application used by real people. Along the way it covered functions, modules and objects; developer tools and version control; scripting and automation; data structures and algorithms; databases and SQL; web development; testing and code quality; APIs and networking; concurrency and performance; packaging and deployment; and software design. The IT foundations courses added hardware and support, Linux, networking, cloud computing and security. Each course used the same small coffee roaster, and the capstone showed how all of those skills combine in one piece of work.

Many directions lead on from here. Junior developer and software tester roles use the full range of the program. Data analysis and automation roles build on the scripting, SQL and data courses. DevOps and cloud roles build on packaging, deployment, Linux and the cloud course. The Python Institute's PCEP and PCAP certifications are common next steps for proving Python skills formally, and the site's other programs, from cybersecurity to the cloud certifications, build on the same foundations. Whatever you choose, keep the habits this course practised: listen to users, agree scope, write things down, test at the boundaries, review each other's work and make deployment boring.